home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1091 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.5 KB
  1. Subject: Re: app_defs
  2. Date: Thu, 28 Jul 94 09:17:34 BST
  3. From: C.J.Ridd@computer-science.birmingham.ac.uk
  4. Precedence: bulk
  5.  
  6. Warwick writes:
  7. >It may be useful to have a `type' code for each atrribute-value pair in
  8. >the app_defs.sys file, to facilitate editing via a tool.  For example:
  9. >
  10. >
  11. >*.papyrus*.key.openFile: KEY = ^O
  12. >*.papyrus*.font:         FNT = Gemini 10pt
  13. >*.papyrus*.key.newFile:  KEY = 0x00380402=F1   // Pretend this is the F1 code
  14. >*.papyrus*.fgColor*:     COL = Purple
  15. >*.papyrus*.bgColor*:     COL = 0x00150315   // Pretend this is a nice colour
  16. >*.tempFile*:             FIL = f:\tmp
  17. >*.foo.name*:             TXT = Hello World
  18. >
  19. ><attribute-pattern> ":" <type> "=" <value>
  20.  
  21. The type would not be required if we could more completely specify the
  22. attribute-pattern string. eg <application name>.<function>.<attribute>
  23. papyrus.opendoc.key    "^O"
  24. papyrus.opendoc.name    "Open..."
  25. papyrus.default.font    "ITC Garamond Book 11pt"
  26. papyrus.default.geometry    800x600+0+0
  27. *.tmpdir.name        U:\tmp
  28.  
  29. Each standard 'function' (not sure this is the best word for it) would
  30. have a number of well-defined attributes like in the example above.
  31.  
  32. Different types for the values could be handled, perhaps you want to
  33. define a key in terms of a scancode.
  34. aardvark.find.key    0x01020304
  35.  
  36. I'm uncertain about the idea of application-types... How many dtp
  37. packages or word processors is a user likely to have? Would it really
  38. be *useful* to be able to define a different key for 'Quit' just for
  39. image processing apps?
  40.  
  41. >chrisridd:
  42. >>What we *should* be doing, IMHO, is proposing and voting for the
  43. >>existence of a shortcut file or files, and only then discussing the
  44. >>precise contents of it. The whole voting period should be much shorter
  45. >>too, as this list is very active :-) Say two weeks per vote.
  46. >
  47. >Voting before discussion?  That's not very democratic.  It's like voting
  48. >for a parliament, THEN letting them discuss policy.
  49.  
  50. Well, you missed my point (or maybe I didn't make it too well :-)
  51. which was that we should all *agree* to the principle of having a
  52. such-and-such, and only then fully defining it. Maybe voting on the
  53. principle would be too strong though...
  54.  
  55. >Preclude discussion and you end up with
  56. >the type of standards comittees you often get in industry:  where
  57. >everyone is just trying to make THEIR PRODUCT the standard, regardless
  58. >of its merits.
  59.  
  60. Hmmm. This sounds mighty similar to the gem toolkit discussion/flame fest.
  61.  
  62. --Chris
  63.  
  64. X.400: g=chris;s=ridd;o=nhs imc;ou1=cosit;a=attmail;p=nhs imc;c=gb
  65. Cix: chrisridd@cix
  66.  
  67.